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DETAILED ACTION 

1. Claims 1-13, 15-28 and 30 are subject to examination. Claims 14 and 29 are cancelled. 

Response to Arguments 

2. Applicant's arguments with respect to the claims have been considered but are moot in 
view of the new ground(s) of rejection. 

Claim Rejections - 35 USC §101 
35 U.S.C. 101 reads as follows: 

' Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

3. Claims 1-13 and 15 are rejected under 35 U.S.C. 101 because the claimed invention is 
directed to a non-statutory subject matter. The claim 1 contains modifying URLs step that do not 
produce a concrete and tangible result. Modifying alone is not producing a concrete and 
tangible result. It's not until the result of the modifying, i.e., serving the select content to the 
client is accomplished (i.e., for example, using a serving step) that it becomes a tangible result, 
which enables any usefulness of having done the modifying to be realized (please see the 
claimed subject matter of claim 1, which is missing the serving step after the modifying). 



Claim Rejections - 35 USC § 112 
The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 
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The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter, which the applicant regards as his invention. 

4. Claims 1,16 and their dependent claims are rejected under 35 U.S.C. 1 12 5 second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject 
matter which applicant regards as the invention. 

Claim 16 recites the limitation "the load balancing array". There is insufficient 
antecedent basis for this limitation in the claim (Please see MPEP 706.03(d)). 

Claim 1 recite the limitations, at line 4, "a load balancing array". These limitations are 
indefinite for failing to particularly point out and distinctly claim the subject matter in the claim 
as per MPEP rules and guidelines, MPEP 706.03(d). It is not apparent what the array is about . 

Claims 1, 16 and their dependent claims are rejected under 35 U.S.C. 112, second 
paragraph, as being incomplete for omitting essential steps/elements/structural cooperative 
relationships of elements, such omission amounting to a gap between the 
steps/elements/necessary structural connections. See MPEP § 2172.01. The omitted 
steps/elements/necessary structural connections are: Usage of multiple packets and multiple 
load balancing servers (e.g., at lines 8 and 9 of claim 1, among other places that refer to load 
balancing) for accomplishing the (respective) load balancing, because a single packet cannot be 
load balanced to a single load balancing server, (the single packet is just assigned to the server 
and not load balanced), Usage of network in the body of the claimed subject matter to 
accomplish the load balancing. Without network it is not possible to accomplish the load 
balancing. A request is missing for the response packet of line 20 of claim 1 (similarly claim 16, 
lines 18-19). Steps/elements relating/linking/functional relationship the parsing step , (with), 
( after) the response packet is sent directly to the requesting client (claim 1, lines 15 -18) 
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(similarly claim 16, lines 14-17). (There is a gap between the load balancing and the parsing and 
are unrelated. Similar applies to claim 16, which does not contain element that the load balancing 
and the parsing). 

Claims 1 and 16 recite the limitations, " to be ". These limitations are indefinite for 
failing to particularly point out and distinctly claim the subject matter in the claim as per MPEP 
rules and guidelines. 

Claims 1 and 16 recite the limitations, " to serve ". These limitations are indefinite for 
failing to particularly point out and distinctly claim the subject matter in the claim as per MPEP 
rules and guidelines. It is not clear to whom the content is to be served. 

The terms " outgoing HTML pages", " select content" in claims 1 and 16 are relative 
terms, which renders the claim indefinite. It is not apparent what the "outgoing" and "select" are 
related to. 



Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

6. Claims 1-4, 7, 8, 13, 15-19, 22, 23, 28 and 30 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Zisapel-Radware in view of Hasett-PointCast, Chiu et al., 6,701,363, 



IBM (Hereinafter Chiu-IBM) and "Official Notice". 
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7. As per claims 1, 15, 16 and 30, Zisapel-Radware teaches a process and an apparatus (e.g., 
figure 1C, abstract) to implement routing packets through a load balancing array of servers 
across a network in a computer environment (e.g., router balancing load among cluster of servers 
over the network, figures 1A - 1C, paragraph 33, page 3), 

a scheduler that is designated as active scheduler for a load balancing array (e.g., usage 
of load balancing servers, content servers, SI, Sn, figures 1 A - 1C, paragraph 33, page 3); 

wherein all incoming packets from requesting clients destined for the load balancing 
array are routed through said scheduler (e.g., LB1 load balancing server also scheduling client 
requests for LB2 load balancing server, figures 1 A - 1C, paragraphs 33 and 34, page 3); 

in response to receiving a request packet from a requesting client at the scheduler, routing 
and load balancing the request packet (e.g., usage of client requests, paragraphs 33 and 34, page 
3) to a load balancing server (e.g., LB1 load balancing server also scheduling client requests for 
LB2 load balancing server, figures 1 A - 1C, paragraph 33, page 3); 

in response to receiving the request packet at the load balancing server, routing and load 
balancing the request packet to a back end Web server (e.g., LB2 load balancing server balancing 
load among content servers, SI, Sn, figures 1 A - 1C, paragraph 33, page 3); 

wherein the back end Web server's response packet to the request packet is sent to the 
load balancing server (e.g., SI, Sn, content servers supporting client requests through LB2 load 
balancing server, paragraphs 8-10, pagel); and 

in response to receiving the response packet at the load balancing server, sending the 
response packet directly to the requesting client (e.g., LB2 load balancing server forwarding 
response from content servers, SI, Sn, to the clients, paragraphs 8-10, pagel). 
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Zisapel-Radware also teaches handling of multiple requests for a client (e.g., paragraph 
36, page 3). 

However, Zisapel-Radware does not specifically mention about a request containing 
multiple packets and a scheduler supporting multiple clients . 

Hasett-PointCast clearly teaches a request containing multiple packets (e.g., abstract, col., 
7, lines 5 - 40, col., 3, lines 34 - 65) and a scheduler supporting multiple clients (e.g., abstract, 
col., 7, lines 5 - 40, col., 3, lines 34 - 65). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Zisapel-Radware with Hasett-PointCast in order to 
facilitate the scheduler to support multiple clients because the requests from the multiple clients 
would be processed by the scheduler. A request having multiple packets would help the request 
communicated from a client to the scheduler. The scheduler would receive requests from the 
clients and would forward the requests so that the requests from the clients are properly handled. 

Zisapel-Radware and Hasett-PointCast do not mention about parsing outgoing HTML 
pages to determine select content to be served by a content delivery network and modifying 
URLs for the select content in the HTML page in a response packet in order to serve the select 
content from the content delivery network wherein HTML pages that have modified URLs are 
cached to improve performance. 

Chiu-IBM discloses parsing outgoing HTML pages to determine select content to be 
served by a content delivery network and modifying URLs for the select content in the HTML 
page in a response packet in order to serve the select content from the content delivery network 
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wherein HTML pages that have modified URLs are cached to improve performance, col, 1, line 
1 9 - col, 4, line 7, col, 8, line 9 - col., 10, line 67. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Zisapel-Radware, Hasett-PointCast and Chiu-IBM in 
order to facilitate usage of the parsing and the modifying URLs because the parsing would 
support checking the content for handling the request and the modifying URLs would support 
providing updated content information. The caching would support retaining the URL 
information. 

Zisapel-Radware, Hasett-PointCast and Chiu-IBM do not specifically mention about 
usage of the virtual IP address and requesting by a routing/load balancing device an assignment 
of the virtual IP address for itself. 

"Official Notice" is taken that both the concept and advantages of providing usage of the 
virtual IP address and requesting by a routing/load balancing device an assignment of the virtual 
IP address for itself is well known and expected in the art. For example, Bruck et al., discloses 
these limitations, Rainfinity Inc, e.g., col., 30, lines 24 - 43; Anerousis et al., AT&T, 
2004/0210670 also discloses these limitations, e.g., paragraphs 82, 85 and 131; Bruck et al., 
6,801,949, Rainfinity Inc also discloses these limitations, e.g., col., 36, line 26 - col., 37, line 19; 
Davies et al., 6,108,701 also discloses these limitations, e.g., col., 5, lines 22 - 35; Anerousis et 
al., 6,760,775, AT&T, also discloses these limitations, e.g., usage of hierarchical CPU scheduler, 
HTTP redirect capabilities, redirect proxy acting as a virtual host for redirecting all network 
service requests, col., 13, lines 40 - 54; Chaganty et al., Avaya, also discloses these limitations, 
col., 24, lines 23-35; Devine et al., Worldcom Inc., 2003/0191970 also discloses these 



Application/Control Number: 09/779,071 Page 8 

Art Unit: 2154 

limitations, paragraph 145; Gourlay, 6,850,980, Cisco, also discloses these limitations, col., 1, 
lines 39 - 56 of "Background of the Invention". 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include the virtual IP address and requesting by a routing/load balancing device an 
assignment of the virtual IP address for itself with the teachings of Zisapel-Radware, Hasett- 
PointCast and Chiu-IBM in order to facilitate requesting and assigning the virtual IP address 
because the virtual IP address would be utilized to communicate information from other devices 
on network to the routing/load balancing device. Using a well-known concept of having a single 
virtual IP address that can be used by multiple devices wherein one of the devices is assigned the 
VIP at a time would enhance the routing/load balancing device to receive packets from devices 
over the network using the assigned virtual IP address in order for routing the received packets. 
Using the virtual IP address routing/load balancing device would communicate with remote 
device over the network. The assigned virtual IP address would provide a client device to send a 
request to the routing/load balancing device. 

8. As per claims 2 and 17, Zisapel-Radware, Hasett-PointCast and Chiu-IBM teach the 
claimed limitations as rejected above. Zisapel-Radware also teaches the following: 

scheduler is a load balancing server and routes and load balances client requests to itself 
(e.g., LB1 load balancing server scheduling client requests for itself, figures 1 A - 1C, paragraph 
33, page 3). 

9. As per claims 3 and 18, Zisapel-Radware, Hasett-PointCast and Chiu-IBM teach the 
claimed limitations as rejected above. Zisapel-Radware also discloses electing a load balancing 
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server (e.g., selection of LB1 or LB2 or LB3, paragraphs 33 and 42) among a plurality of load 
balancing servers (e.g., LB1 or LB2 or LB3, paragraphs 33 and 42) as a new scheduler (e.g., 
usage of LB1 or LB2 or LB3 upon availability for new (next) scheduling, paragraphs 33 and 42). 
(Note: the new scheduler is not limited to replacing another scheduler). 

However, Zisapel-Radware, Hasett-PointCast and Chiu-IBM do not specifically mention 
about the use of detecting the failure of the server. "Official Notice" is taken that both the 
concept and advantages of providing to detect the failure of the server is well known and 
expected in the art. For example, Coile et al., 6,108,300 (Hereinafter Coile) teaches these 
limitations, e.g., col., 5, lines 3 - 24, e.g., col., 6, lines 40 - 62, col., 8, lines 2 - 28. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include detecting the failure of the server with the teachings of Zisapel-Radware, 
Hasett-PointCast and Chiu-IBM in order to facilitate handling of system performance in an event 
of the scheduler failure because upon failure of the scheduler the system would know what client 
requests are not handled by the failed scheduler. The system would have another server to 
handle the job of the failed server. 

10. As per claims 4 and 19, Zisapel-Radware, Hasett-PointCast and Chiu-IBM teach the 
claimed limitations as rejected above. However, Zisapel-Radware, Hasett-PointCast and Chiu- 
IBM do not specifically mention about the use of server detecting the failure of any load 
balancing servers among a plurality of load balancing servers and the server stops routing 
packets to any failed load balancing servers. "Official Notice" is taken that both the concept and 
advantages of providing server detecting the failure of any load balancing servers among a 
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plurality of load balancing servers and the server stops routing packets to any failed load 
balancing servers, is well known and expected in the art. For example, Coile et al., 6,108,300 
(Hereinafter Coile) teaches limitations, "server detecting the failure of other load balancing 
servers (e.g., col., 12, lines 35 - 54, col., 6, lines 40 - 62, col., 8, lines 2 - 28)" and "the server 
stops routing packets to any failed load balancing servers/back end Web servers (e.g., col., 12, 
lines 35 - 54, e.g., col., 6, lines 40 - 62, col., 8, lines 2 - 28)". 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include server detecting the failure of any load balancing servers among a plurality 
of load balancing servers and the server stops routing packets to any failed load balancing 
servers, with the teachings of Zisapel-Radware, Hasett-PointCast and Chiu-IBM in order to 
facilitate assigning client requests to another load balancing server instead of the failed load 
balancing server because stopping to route packets to the failed load balancing server would 
prevent dropping packets. Rerouting to the packets to the other load balancing server will help 
process the client requests. 

11. As per claims 7, 8, 22 and 23, Zisapel-Radware, Hasett-PointCast and Chiu-IBM teach 
the claimed limitations as rejected above. However, Zisapel-Radware, Hasett-PointCast and 
Chiu-IBM do not specifically mention about the use of server decrypting and encrypting packet 
for an SSL session. "Official Notice" is taken that both the concept and advantages of providing 
server decrypting and encrypting packet for an SSL session, is well known and expected in the 
art. For example, Hankinson et al., 6,799,202 (Hereinafter Hankinson) teaches limitations, 
"server decrypting and encrypting packet for SSL session (e.g., col., 3, lines 2 - 65)". 



Application/Control Number: 09/779,071 Page 1 1 

Art Unit: 2154 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include server decrypting and encrypting packet for an SSL session, with the 
teachings Zisapel-Radware, Hasett-PointCast and Chiu-IBM in order to facilitate secure 
communicating between the client and the Web server because for processing and forwarding the 
packet to the Web server, the load balancing server will decrypt the packet when it receives from 
the client. The load balancing server will receive the response packet from the Web server, and 
it will encrypt the response packet before sending to the client. Using well-known SSL session 
implementation, the web server and the client will have direct secure communication. 

12. As per claims 13 and 28, Zisapel-Radware, Hasett-PointCast and Chiu-IBM teach the 
claimed limitations as rejected above. However, Zisapel-Radware, Hasett-PointCast and Chiu- 
IBM do not specifically mention about the use of detecting and stop routing request packets to 
failed back end Web servers. "Official Notice" is taken that both the concept and advantages of 
providing detecting and stop routing request packets to failed back end Web servers is well 
known and expected in the art. For example, Coile et al., 6,108,300 (Hereinafter Coile) teaches 
limitations, "server detecting the failure of other load balancing servers (e.g., col., 12, lines 35 - 
54, col., 6, lines 40 - 62, col., 8, lines 2 - 28)" and "the server stops routing packets to any failed 
load balancing servers/back end Web servers (e.g., col., 12, lines 35 - 54, e.g., col., 6, lines 40 - 
62, col., 8, lines 2 - 28)". 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include detecting and stop routing request packets to failed back end Web servers 
with the teachings of Zisapel-Radware, Hasett-PointCast and Chiu-IBM in order to facilitate 
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accessing the other web server in an event of the web server failure because upon failure of the 
web server, other web server would help support the client requests. By stopping to route the 
packets to the failed web server would help prevent packets from dropping and the other web 
server would then handle the client requests. 

13. Claims 5 5 6, 20, 21, are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Zisapel-Radware, Hasett-PointCast, Chiu-IBM, "Official Notice" and in view of Masters 
6,374,300 (Hereinafter Masters). 

14. As per claims 5, 6, 20, 21 , Zisapel-Radware, Hasett-PointCast and Chiu-IBM teach the 
claimed limitations as rejected above. However, Zisapel-Radware, Hasett-PointCast and Chiu- 
IBM do not specifically mention about the server scheduling sessions to servers based on a 
cookie or session ID and use of cookie injection to map a client to a specific server. 

Masters teaches about the concept of server scheduling sessions to servers based on a 
cookie or session ID (e.g., abstract, col., 10, lines 8-61), and use of cookie injection to map a 
client to a specific server (e.g., abstract, col., 10, lines 8 - 61, col., 13, lines 1- 24). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Zisapel-Radware, Hasett-PointCast and Chiu-IBM with 
Masters in order to facilitate scheduling based on cookie for persistent connection with the web 
server because using the cookie the client request can be routed to a previously selected 
destination web server associated with the client. The client will be able to continue using the 
same web server support. As per Masters teachings, the cookie information can be manipulated 
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as necessary. Hence, the client will be able to continue communicating with the server in a 
direct persistent manner. 

15. Claims 9-12, 24-27, are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Zisapel-Radware, Hasett-PointCast and Chiu-IBM and "Official Notice" in view of Masters 
6,374,300 (Hereinafter Masters). 

16. As per claims 9-12, 24-27, Zisapel-Radware, Hasett-PointCast and Chiu-IBM teach the 
claimed limitations as rejected above. However Zisapel-Radware, Hasett-PointCast and Chiu- 
IBM do not specifically mention about the requesting client keeping connection alive with the 
server. "Official Notice" is taken that both the concept and advantages of the requesting client 
keeping connection alive with server, is well known and expected in the art. Bowman-Amuah, 
6,289,382, Anderson Consulting, discloses these limitations, col, 79, line 15 - col., 80, line 64, 
col., 258, lines 1 - 67. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include the requesting client keeping connection alive with the server, with the 
teachings of Zisapel-Radware, Hasett-PointCast and Chiu-IBM in order to facilitate secure 
communicating between the client and the Web server because using well-known SSL session 
implementation, the web server and the client will have direct secure communication as long as 
the connection between the web server and the client is alive. 

Zisapel-Radware, Hasett-PointCast and Chiu-IBM do not specifically mention about 
URL based scheduling of packets and the load balancing server performing hash scheduling of 
packets. Masters teaches about URL based scheduling of packets (e.g., col., 5, lines 18 - 65), 
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persistent connections in paths requiring persistent connections (e.g., col., 5, lines 22 - 59, col., 
6, lines 8-31) and the load balancing server performing hash scheduling of packets (e.g., col., 
15, lines 45 - col., 16, lines 21) and uses hash group based persistence to maintain its persistence 
tables (e.g., col., 5, lines 22 - 59, col., 15, line 57 - col., 16, line 24). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings Zisapel-Radware, Hasett-PointCast and Chiu-IBM with 
Masters in order to facilitate secure communicating between the client and the Web server 
because the URL information in the https packet would provide information of the resource, 
which the client needs to access. The scheduling with hashing of packets will provide direct 
secure communication between the web server and the client. 

Conclusion 

Examiner has cited particular columns and line numbers and/or paragraphs and/or 
sections and/or page numbers in the reference(s) as applied to the claims above for the 
convenience of the applicant. Although the specified citations are representative of the teachings 
of the art and are applied to the specific limitations within the individual claim, other passages 
and figures may apply as well. It is respectfully requested from the applicant in preparing 
responses, to fully consider the references in entirety, as potentially teaching, all or part of the 
claimed invention, as well as the context of the passage, as taught by the prior art or disclosed by 
the Examiner. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Haresh Patel whose telephone number is (571) 272-3973. The 
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examiner can normally be reached on Monday, Tuesday, Thursday and Friday from 10:00 am to 
8:00 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Nathan Flynn can be reached at (571) 272-1915. The fax phone number for the 
organization where this application or proceeding is assigned is (571) 273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 

Haresh Patel 
April 12, 2007 



